Atari Mega Archive 1/Atari Mega Archive - Volume 1.iso/lists/gem/l_1199/970

Internet Message Format | 1994-08-27 | 16KB

Date: Fri, 22 Jul 94 03:11 CDT
From: [e-mail] (Evan K. Langlois)
To: [e-mail]
Subject: GEM apps, in general
Precedence: bulk


I'll post some code in my next message that handles button events.  Please
compile it.  It demonstrates soem very simple and powerful ideas.  In fact,
remove the printf's and stick in pointers to functions and you'll have a
C program that manages button events very well.  Use ObjC messages for the
printf's and it gets better.

The idea of the code is to show that you don't need to call graf_mkstate()
a bunch of times in a loop.  How many art packages look for a click and
then call graf_mkstate() in a loop?   This prevents any other events and
its wrong.  You can use timer events to animate an icon, and rectangle
events for other effects, and still recieve redraw messages and such while
a user is holding a button down - even recieve more button events!!

Now, why is holding the right mouse button down to click in a background
window archaic?  Well, I think that holding the right button will stop
a TOP message from being delivered (I don't remember nor care) and I know
that until recently, most people did not know that GEM could handle more
than one button at once without polling.

If the user clicks the mouse on a selectable and completely unobscured,
visible object, then why not select it instead of topping the window?  Since
there is a border area on most dialogs, you can use that to top it, and
and partially obscured object can be used to top the window.  I know some
of you are worried about not being to top a window - does the new condition
or forcing the object to be completely visible satisfy your needs?

As for key events and the "top" window, you should note that the top window
does always get key events - if you call a dialog a window (even a modal one).
Also note that if you select something in the menu, like change font, then
this affects the top window too .. but what if you have a dialog over that
window?   What if "Change Font" calls up a dialog in a window?  If won't
change the font of itself!!  It changes the font of a different window.
Application focus and key focus are not always different.

As for the sending of key events, I would like to propose an extension to
the drag-drop protocol.  If you implement a drag, but the application you
drag to doesn't support being dropped on, then you can still "pipe" ascii
data to that window by sending a key event to the application for each
character.  This will be painfully slow, but it will work.

As for point to type, make it an option in the app-defs file.  Its easy to
do for one application, but making it global is kinda screwy as its basically
doing finding the window, finding the app that owns the window, like drag/drop
but then it sends a copy of teh key event the OS sent to the other app.

As to Ken and WinLIB Pro:

========================================================================
I'm simply saying that the foreground application gets more 'attention'
than background tasks. No 'wasted' CPU time at all, just 're-allocated' CPU
time. After all, the application the user is currently interacting with will
be getting most of the mouse activity, don't you think? :-)
========================================================================

This statement is WRONG.  There are no foreground and background tasks.
Think of it this way.  An application waiting for an event is not running
and is not using the CPU.  An application that is executing code is
running.  Under SingleTOS, or Geneva, while one application runs, no
other application can be running, and when the AES is called, GEM begins
to poll for events and either gives an event where it needs to, or lets the
AES call return.  It determines things like how much two cuncurrent programs,
like a DESK ACC and an APP (or with GENEVA multiple apps) on a round-robin
basis, so every program gets more or less EQUAL CPU share.  Task switching
only happens during an AES call.

Under MultiTOS, multiple applications runs at once, so when does the AES
poll for events?  Answer - always.  Having programs run while another
polls makes MultiTOS seem very slow, even if only one application is
running, and more applications running means more code running at once.
What is some of those programs don't block for evnt_multi and they use
a 0ms timer to poll for events?   Well they will wind up using ALOT of
CPU time slowing the system to a baby-crawl.  Just evnt_multi calling
very often is ALOT of overhead, and then calling objc_find is worse.
Doing all this during the MultiTOS polling is too much to handle.  And
don't forget that you can have tasks that aren't GEM, and they will
have to complete for CPU time too!!

Under the newer MultiTOS, instead of polling for events, interrupts trigger
MiNT device drivers that wake up the AES and let it know an event is
available.  This is ver yfast and efficient and it means that there is no
more polling.  No polling means that when your app runs, it doesn't have to
compete with the AES code polling the mouse in a tight loop, so it runs
fast.  Also note that in neither version of MultiTOS do you need to give
up CPU time.  You can do computations all day long and never make an AES
call and the system will be fine (your windows get dirty though!).  Heavy
computation is a good reason to use tfork() - it is backwards compatible
to TOS (making it a single-tasking function call) and allow you to thread
a long function call.

Using Timer events to poll means that one application will east CPU slices
from every other program - those in windows, TOS background tasks, daemons,
or other AES programs that attempt to do concurrent tasks.  These events
are made by a programmer that assumes the user is using his program and
is not using any other, and that the performance of the rest of the system
is allowed to suffer to make his life easier.

This is simply bad programming.  There are better ways.  In General, your
programs should always sit and wait for something to happen, NOT check and
see if something is happening.  The first is highly efficient and is just
as fast under single-TOS and will free an incredible amount of CPU under
the new MultiTOS.  The second will be great under single-TOS, slow under
MultiTOS and you will see it HOG the CPU under the new MultiTOS using simple
utils like TOP.

========================================================================
I do not like the idea of having buttons function in background windows
unless that particular dialog is INTENDED to work that way.  There should
be options for doing this for things like tool boxes and multiple
non-overlapping pannels, but otherwise, I like the way GEM works normally.
========================================================================

Give examples of where the guidelines I give above fail!  Using the desktop
as a test, I only see benefits.

========================================================================
I'm not sure I follow your comment.  My -experience- is that I do not know
assembly language, and therefore have no real use for an assembly level
debugger.  What on earth can you possibly object to in that?
========================================================================

In my EXPERIENCE I have used both kinds of debuggers.  Both have their
uses.  I do know assembly language, 3 or 4 of them, but I fail to see
what ANY of this has to do with GEM.  Will using TIMER events slow the
system?  Yes!   Why?   Because the program is running instead of waiting.
Waiting means you are on a queue, ready for some other code to give you
your fix so you jive again :-)   Running means your eating CPU and if you
east CPU, you better do something GOOD with it since its limited resource.
TIMER events are sent to every app that wants them, not just the top one.
Calling evnt_multi means passing half a dozen parameters on the stack,
including lots of LEA's, then copy lots of these to the intin/intout arrays,
then lookup the control values to the calls (whoops, missed a JSR in there!
this ain't C++, so its not inline), then we call a TRAP (and that takes
forever in itself), no